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SECTION  1 .  GENERAL 


1.1  Purpose. '  The  purpose  of  the  AFIRMS  Management  Plan  is  to  identify  the 
requirements  for  developing,  coordinating,  and  executing  the  AFIRMS 
Evolutionary  Implementation  Plan  (EIP)  as  well  as  the  AFIRMS  support  plans. 

1.2  Objectives.  The  objectives  of  the  AFIRMS  Management  Plan  are  to: 

•  Provide  for  centralized  control  and  decentralized  execution  of  AFIRMS 
development,  implementation,  and  operation. 

•  Specify  the  technical  management  tasks  required  for  AFIRMS  program 
development . 

•  Assign  responsibilities  for  accomplishing  each  of  these  tasks. 

•  Focus  program  management  activities  on  the  preparation  and  execution 
of  the  AFIRMS  EIP  and  related  support  plans. 

•  Specify  support  plans  required  for  the  AFIRMS  program. 

•  Assign  responsibilities  for  management  plan  actions. 


1 . 3  Scope .  The  AFIRMS  Management  Plan  provides  the  top  level,  integrative 
frame  of  reference  for  the  AFIRMS  Program.  As  such,  it  serves  as  the  AFIRMS 
Information  Systems  Program  Plan  (ISPP)  by  providing  overall  organization, 
management  milestones,  and  task  responsibilities  for  the  development  of 
AFIRMS.  The  AFIRMS  Management  Plan  focuses  on  the  processes  which  provide 
technical  and  administrative  control  of  the  program.  Planning,  Programming, 
and  Budgeting  System  (PPBS)  actions  and  Program  Objectives  Memorandum  (POM) 
requirements  are  not  included  in  this  Plan. 

The  AFIRMS  Management  Plan  consists  of  the  basic  document  and  Annexes  A 
through  H.  Annex  A  provides  the  overall  schedule  of  management  reviews  and 
program  milestones.  It  does  not  include  the  specific  software  development  or 
hardware  acquisition  schedules  nor  does  it  set  forth  support  activity 
scheduling  such  as  the  training  schedules  or  the  test/acceptance/turnover 
schedules.  Such  technical  schedules  are  included  in  the  Evolutionary 
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Implementation  Plan  master  schedule  and  the  schedules  of  the  individual 
Segment  Plans.  Annexes  B  through  H  are  technical  plans  required  to  support 
the  AFIRMS  program.  These  annexes  detail  specific  requirements, 
responsibilities,  procedures,  or  policies  that  apply  throughout  the  AFIRMS 
program.  The  two  most  important  annexes  are  the  Evolutionary  Implementation 
Plan  (Annex  B)  and  the  Configuration  Management  Support  Plan  (Annex  C)  since 
the  former  provides  the  AFIRMS  "route  map"  and  the  latter  provides  the  AFIRMS 
"checkpoints."  System  Interface  actions,  specifications,  and  schedules  are 
contained  in  the  Systems  Interface  Support  Plan  (Annex  D) .  This  plan 
identifies  target  Air  Force  standard  systems  as  well  as  MAJCOM  unique  systems 
with  which  AFIRMS  is  to  interface.  Other  annexes  provide  support  plans  for 
key  AFIRMS  issues  such  as  security  (Annex  E) ,  training  (Annex  F) ,  maintenance 
(Annex  0),  and  manpower  (Annex  H) . 


1.4  Abbreviations  and  Acronyms. 


Alaskan  Air  Command 
-  Air  Force 


AF/SI 


AF/SISC  - 
AF/X00  - 
AFIRMS  - 


Air  Force  I  formation  Systems 

Air  Force  Standard  Information  Systems  Center 

Air  Force  Directorate  of  Operations 

Air  Force  Integrated  Readiness  Measurement  System 

Air  Force  Logistics  Command 

Air  Force  Regulation 

Air  Force  Reserves 

Air  National  Guard 

Air  Tasking  Order 

Configuration  Control  Board 

Combat  Fuels  Management  System 

Configuration  Item  Index 

Configuration  Requirements  Committee 

Configuration  Status  Accounting  System 
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- 


CSMS 

- 

Combat  Supplies  Management  System 

DRD 

- 

Data  Requirements  Document 

EA 

- 

Economic  Analysis 

ECP 

- 

Engineering  Change  Proposal 

EIP 

- 

Evolutionary  Implementation  Plan 

FD 

- 

Functional  Description 

HQ 

- 

Headquarters 

ISPP 

- 

Information  Systems  Program  Plan 

JCS 

- 

Joint  Chiefs  of  Staff 

LPP 

- 

Learning  Prototype  Phase  of  AFIRMS 

MAC 

- 

Military  Airlift  Command 

MAJCOM 

- 

Major  Command 

OPlan 

- 

Operations  Plan 

OPR 

- 

Office  of  Primary  Responsibility 

PACAF 

- 

Pacific  Air  Forces 

PAO 

- 

Program  Action  Officer 

PAR 

- 

Problem  Action  Report 

PD 

- 

Product  Descriptions 

PMD 

- 

Program  Management  Directive 

PMO 

- 

Program  Management  Office 

POM 

- 

Program  Objectives  Memorandum 

PPBS 

- 

Planning,  Programming,  and  Budgeting  System 

PSC 

- 

Published  Under  Separate  Cover 

QA 

- 

Quality  Assurance 

SAC 

- 

Strategic  Airlift  Command 

SO  A 

- 

Separate  Operating  Agency 

SS 

- 

System  Specification 

3SR 

- 

System  Status  Review 

TBP 

- 

To  Be  Published 

USA? 

- 

United  States  Air  Force 

U5AFE 

- 

United  States  Air  Force,  Europe 

WMP 

- 

War  Mobilization  Plan 

W3MIS 

- 

Weapons  System  Management  Information  System 

AF-CO 1  10/85  dh 


1-3 
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k.  AFR  205-16,  Automated  Data  Processing  (ADP)  Security  Policy, 
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l.  AFR  300-2,  Managing  the  USAF  Automated  Data  Processing  Program,  24 
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m.  AFR  300-6,  Automatic  Data  Processing  Resource  Management,  11  July 
1980.  (Unclassified) 
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SECTION  2.  INTRODUCTION  TO  AFIRMS 


This  section  provides  a  brief  introduction  to  the  Air  Force  Integrated 
Readiness  Measurement  System  (AFIRMS).  A  more  complete  description  is 
provided  in  the  AFIRMS  Functional  Description. 


2.1  AFIRMS  Synopsis.  Accurate  assessment  of  force  readiness  and 
sustainability  has  been  a  constant  concern  of  Air  Force  Commanders  and  their 
staffs.  This  concern  has  been  supported  by  an  intensified  interest  in 
military  capability  (readiness,  sustainability,  force  structure,  and 
modernization  as  defined  in  JCS  MOP  172)  throughout  the  Department  of  Defense. 

In  response,  the  Air  Force  Directorate  of  Operations  and  Readiness  initiated 
the  AFIRMS  Program.  AFIRMS  is  specifically  designed  to  provide  Air  Force 
Commanders  with  a  complete,  timely  and  accurate  assessment  of  their  combat 
capability  (readiness  and  sustainability  as  defined  in  JCS  MOP  172). 


2.1.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to 
perform  tasked  missions  based  on  the  availability  of  specific  resources. 


a.  The  conceptual  requirements  for  AFIRMS  are  two-fold: 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The 
user  can  assess  unit/force  combat  capability  against  any  planned 
or  ad  hoc  tasking,  e.g.,  War  Mobilization  Plan  (WMP),  Operation 
Plan  (Oplan),  Fragmentary  Order,  Air  Tasking  Order  (ATO), 
Contingency  Plan,  etc. 

(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 
AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This 
tool  permits  comparison  of  readiness  and  sustainability  by 
fiscal  year  and  can  therefore  highlight  the  impact  of 
appropriation  changes.  Thus,  changes  in  funding  are  related  to 
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changes  in  force  readiness  and  sustainability.  Also,  senior  Air 
Force  decision  makers  are  supported  during  budget  deliberations 
and  Air  Force  budget  allocations. 

b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments. 
AFIRMS  has  two  integrative  dimensions.  First,  all  applicable 
resources  and  their  usage  interactions  are  considered.  For 
example,  in  sortie  capability  assessment,  AFIRMS  evaluates 
capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies, 
and  their  generative  components  (such  as  spares  for  aircraft, 
training  qualifications  for  aircrew,  load  crews  for  munitions, 
and  hot  pits  for  fuel).  Second,  other  automated  systems  (such 
as  the  Combat  Supplies  Management  System  (CSMS),  Combat  Fuels 
Management  System  (CFMS),  Weapon  System  Management  Information 
System  (WSMIS),  etc.)  outputs  are  integrated  into  capability 
assessment  calculations  through  system  interfaces  between  those 
systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than 
the  data  upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a 
user  orientation  toward  quality  assurance  of  source  data.  Unit 
and  other  data  input  level  users  are  provided  effective  tools  to 
accomplish  their  daily  activities  and  therefore  develop  a  vested 
interest  in  AFIRMS  data  currency  and  validity.  Capability 
assessment  data  can  then  be  extracted  for  use  by  higher  or 
parallel  users  with  maximum  confidence  in  its  validity. 


2.1.2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess 
readiness  capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system, 
tasking  must  be  converted  into  a  standard  format  recognized  by 
AFIRMS.  Tasking  is  defined  in  AFIF.MS  to  the  unit  level  and  may 
consist  of  actual  tasking,  standard  tasking,  or  contingency  tasking. 
Any  of  these  taskings  can  be  defined  within  specified  WMP  or  OPlan 
constraints,  at  the  option  of  the  user.  Likewise,  the  tasking  may  be 
defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures 
that  information  about  inventory  status  is  available  and  accurate. 
Wherever  possible,  this  data  is  obtained  by  interface  with  other 
functional  systems.  As  with  tasking,  resource  information  can  be 
defined  for  actual,  hypothetical,  or  contingency  situations,  either 
present,  historic,  or  future. 
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c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to 
perform  is  the  essential  function  of  AFIRMS.  The  tasking  and 
resource  data  are  processed  to  determine  how  much  of  the  specified 
tasking  can  be  accomplished  with  the  resources  available.  Ability  to 
perform  is  evaluated  in  terms  of  the  task  metric  (sorties,  etc.)  and 
the  cost  metric  (dollars)  to  provide  readiness/sustainability  and 
dollars  to  readiness  assessments. 

d.  Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and 
presentation  ensure  the  proper  grouping  and  display  of  data  to 
provide  useful  information  at  the  unit,  major  command  and  HQ  USAF. 
Aggregation  refers  to  the  creation  of  a  composite  understanding  of 
capability  for  several  units. 

2.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes  AFIRMS. 
A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document . 


a.  Functional  Description  (FD).  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

o.  AFIRMS  Management  Plan.  The  Management  Plan  provides  the  top  level, 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

i.  System  Specification.  The  AFIRMS  System  Specification  adds  the 

design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems:  HQ  USAF,  HQ  USAFE  (MAJCOM) ,  and  Wing 
(unit).  The  system  specification  also  assigns  functions  required 
within  each  subsystem.  The  system  specification  details  the  overall 
architecture,  intersite  interface  gateways,  processing  logic  flows 
and  the  communications  network  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 

specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  ani 
the  Wing  ( uni t/wing/sq uadron) .  Subsystem  specifications  letail  the 
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specific  design  and/or  performance  requirements  of  the  system  at  tha 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 

Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  [JSAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
Wing  ( unit/wing/ squadron) .  These  specifications  describe  the 
database  architecture,  size,  and  content,  as  well  as  logical  data 
relationships  for  the  functions  performed  at  each  of  the  AFIRMS 
levels . 

Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes, 
and  groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  define 
each  type  of  AFIRMS  data  element  (attribute  class). 

Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products 
which  implement  the  AFIRMS  functions  as  input  and  output  tools. 

Transform  and  Model  Descriptions.  The  Transform  and  Model 
Descriptions  document  defines  how  AFIRMS  calculates  the  output  data 
from  the  input  data.  Specific  algorithmic  calculations  are  provided 
Logical  groups  of  algorithms  forming  AFIRMS  models  and  transforms  ar 
described . 


SECTION  3-  SUMMARY  OP  THE  APIRMS  MANAGEMENT  PLAN 


3. 1  Concept.  The  technical  management  of  APIRMS  consists  of  two  elemental 
components  (configuration  and  execution)  and  a  synchronizing  mechanism  (the 
Evolutionary  Implementation  Plan).  All  APIRMS  management  activities  relate  to 
one  of  these  components.  The  Evolutionary  Implementation  Plan  (EIP)  provides 
the  connectivity  for  the  various  activities  within  these  two  components  of 
APIRMS  management. 

Responsibility  for  these  components  is  assigned  to  different  offices  in 
order  to  reduce  the  range  of  issues  that  must  be  handled  by  any  one  office  and 
also  to  provide  both  a  strategic  and  a  tactical  focus  to  APIRMS  management. 

The  Office  of  Primary  Responsibility  (OPR)  ensures  the  accomplishment  of  all 
the  management  efforts  necessary  to  configure  APIRMS.  These  efforts  are 
broadly  grouped  within  two  of  four  functions  of  APIRMS  management:  planning 
and  organizing.  The  Program  Management  Office  (PMO)  is  responsible  for  all  of 
the  efforts  necessary  to  execute  the  APIRMS  Program.  Such  efforts  are  grouped 
within  one  of  the  other  two  functions  of  APIRMS  management:  directing  and 
controlling. 


3.2  Program  Organization.  Management  of  APIRMS  is  accomplished  within  an 
organization  consisting  of  the  Office  of  Primary  Responsibility  (OPR),  the 
Program  Management  Office  (PMO),  an  APIRMS  Steering  Committee  which  also 
serves  as  the  APIRMS  Conf iguration  Control  Board  (CCB),  a  group  of  AFIRMS 
Program  Action  Officers  (PAO's),  and  Configuration  Requirements  Committees 
(CRC)  at  each  participating  major  command  as  well  as  at  the  Air  Staff.  Since 
APIRMS  is  an  evolutionary  implementation,  the  PMO  is  initially  responsible  for 
both  system  development  and  for  system  operation.  Upon  completion  of  the  EIP, 
transfer  of  program  management  responsibility  is  accomplished  from  the  PMO  to 
the  system  manager  of  the  supporting  command  in  accordance  with  AFR  800-4. 
During  the  EIP  period,  the  PMO  depends  upon  a  System  Operation  Program  Action 


AFIRMS  Steering  Committee: 


CHAIRMAN:  Office  of  Primary  Responsibility 
DEPUTY  CHAIRMAN:  Program  Management  Office 

MEMBERS:  Program  Action  Officer  for: 

USAF  PLANS  AND  OPERATIONS 
USAF  INFORMATION  SYSTEMS 
AIR  FORCE  LOGISTICS  COMMAND 
AIR  FORCE  RESERVE 
AIR  NATIONAL  GUARD 
ALASKAN  AIR  COMMAND 
MILITARY  AIRLIFT  COMMAND 
PACIFIC  AIR  FORCES 
STRATEGIC  AIR  COMMAND 
TACTICAL  AIR  COMMAND 
U.S.  AIR  FORCES,  EUROPE 

•  AFIRMS  Program  Action  Officers: 

Each  Steering  Committee  member 
OPR  of  each  functional  system  for 
AFIRMS  interface 
Configuration  Management 
Systems  Interfaces 
Training 
Maintenance 
Security 

Acquisi tion/ Contracts 
Manpower 

Quality  Assurance 
System  Operation 

AFIRMS  Configuration  Requirements  Committees 


AF/XOO 

AF/SISC 


AF/ 

AF/SI 

AFLC/ 

AFR/ 

ANG/ 

AAC/ 

MAC/ 

PACAF/ 

SAC/ 

MAC/ 

USAFE/ 


(as  above) 
(listed  in 
Annex  D) 


CHAIRMAN: 


MEMBERS 


Program  Action  Officer 

of  the  Participating  Command 
Representative  of  each  participating 
subordinate  organization 


In  addition  to  this  management  team,  the  AFIRMS  team  includes  the 
organizations  which  actually  build  AFIRMS.  These  builders  are  AFIRMS  Agent. 
There  are  two  types  of  agents: 

•  Separate  Operating  Agencies  (SOA)  of  the  Air  Force 

•  Contractors 
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3.3  Management  Functions.  Managing  AFIRMS  is  complicated  by  the  evolutionary 
nature  of  the  APIRMS  implementation  concept.  APIRMS  management  faces  complex 
coordination,  interface  and  control  requirements  for  an  APIRMS  implementation 
which  extends  over  a  number  of  years  and  which  includes  functional 
requirements  that  cannot  be  fully  defined  in  advance  for  all  the  major 
commands  without  excessively  delaying  APIRMS  implementation.  Management  of 
APIRMS  in  this  environment  is  four  dimensional: 

•  Participating  Air  Force  Major  Commands 

(the  number  of  MAJCOMs  to  be  implemented) 

•  Depth  of  MAJCOM  participation 

(the  number  of  command  levels  implemented  within  a  MAJCOM) 

•  The  range  of  APIRMS  functional  modules  or  products 

(the  number  of  different  functions  accomplished  by  APIRMS) 

•  The  depth  of  APIRMS  products 

(the  number  of  different  versions  of  an  AFIRMS  function) 

The  APIRMS  Management  Plan  describes  how  this  four  dimensional  effort  is 
planned,  organized,  directed,  and  controlled.  Each  of  the  four  management 
functions  has  a  different  perspective  on  the  four  dimensions  of  APIRMS 
management.  For  example,  the  objective  of  the  planning  activities  is  to 
prescribe  the  AFIRMS  envelope,  the  strategic  issues  of  "what  is  AFIRMS  and 
where  is  APIRMS  going."  At  the  other  end  of  the  management  spectrum,  the 
controlling  function  provides  the  answers  to  the  "where  is  AFIRMS  now"  status 
questions.  In  between  these  poles,  organizing  APIRMS  provides  the  "how  does 
AFIRMS  get  there  from  here"  (the  Evolutionary  Implementation  Plan)  and 
directing  APIRMS  provides  the  "turn  the  APIRMS  crank"  to  accomplish  the  next 
block  of  Evolutionary  Implementation  Plan.  Figure  3-2,  Management  Time  Focus, 
depicts  the  APIRMS  Management  Process.  The  four  management  functions 
(planning,  organizing,  directing,  and  controlling)  are  used  to  organize  the 
tasks  and  processes  necessary  to  APIRMS  that  are  detailed  in  the  following 
sections . 
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SECTION  4.  PLANNING  AFIRMS 


Planning  AFIRMS  identifies  what  AFIRMS  is  and  where  AFIRMS  is  going. 


4.1  Plannning  Objectives.  The  objectives  of  AFIRMS  planning  are  to: 

•  Establish  and  maintain  the  boundaries  of  the  AFIRMS  program. 

•  Establish  and  maintain  the  Functional  Baseline  of  AFIRMS. 

•  Specify  the  Air  Force  systems  with  which  AFIRMS  is  to  interface. 

•  Define  and  prioritize  the  AFIRMS  functional  modules  and  system 
interfaces . 


4.2  Office  of  Primary  Responsibility.  The  Office  of  Primary  Responsibility 
(OPR)  is  the  Air  Force  Directorate  of  Operations  (AF/XOO).  The  OPR  has 
overall  responsibility  for  the  accomplishment  of  AFIRMS.  This  responsibility 
is  fulfilled  through  exercise  of  OPR  authority  to  plan  and  organize  AFIRMS. 

In  the  planning  function,  the  OPR,  as  the  chairman  of  the  Steering  Committee 
and  the  Configuration  Control  Board,  has  final  authority  over  the  definition 
of,  and  functional  requirements  for,  AFIRMS. 


r.  s. 
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4.3  Steering  Committee.  The  AFIRMS  Steering  Committee  provides  user  input  at 
the  highest  level  of  AFIRMS  planning  activities.  The  Steering  Committee  i3 
composed  of  the  OPR,  the  PMO,  the  HQ  US AF  Program  Action  Officer,  the  AF/SI 
Program  Action  Officer,  and  Program  Action  Officers  from  each  participating 
major  command.  The  OPR  prepares  the  agenda  for  the  Steering  Committee 
Meeting.  Committee  members  participate  in  the  definition  of  the  AFIRMS 
Functional  Baseline  and  coordinate  the  functional  baseline  for  concurrence  at 
their  respective  commands.  They  present  the  positions,  requirements,  and 
recommendations  of  their  respective  commands  or  offices  based  upon  the  results 
jf  their  Configuration  Requirements  Committee  meetings.  The  HQ  USAF  PAO  nas 
the  3ame  responsibilities  for  the  Air  Staff  AFIRMS  user  community  that  the 
MAJCQM  PAOs  have  for  AFIRMS  users  within  their  respective  commands. 
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4.3.1  Program  Management  Review.  Review  of  the  APIRMS  program  is 
accomplished  via  quarterly  System  Status  Reviews  (SSR)  conducted  by  the  APIRMS 
Program  manager.  These  reviews  keep  the  APIRMS  participants  abreast  of 
current  progress  within  the  Evolutionary  Implementation  Plan.  The  members  of 
the  APIRMS  Steering  Committee  attend  these  quarterly  Systems  Status  Reviews  in 
preparation  for  the  Steering  Committee  meeting,  which  immediately  follows  each 
quarterly  review. 


4.3.2  Configuration  Control  Board.  The  Steering  Committee  also  serves  as  the 
APIRMS  Configuration  Control  Board.  Conf iguration  issues  are  the  first  item 
of  business  on  the  agenda  for  each  quarterly  committee  meeting.  System  level 
configuration  issues  such  as  APIRMS  architecture,  technical  standards,  data 
dictionary,  and  intersite  gateways  are  addressed  by  the  full  committee 
membership.  Configuration  issues  which  are  limited  to  a  MAJCOM  or  other 
APIRMS  segment  are  addressed  before  the  Steering  Committee  Meeting  by  a 
subgroup  of  the  Steering  Committee  consisting  of  the  OPR,  the  PMO,  the  AP/SI 
PAO,  and  the  MAJCOM  PAOs  affected  by  the  configuration  issue.  The  results  of 
such  subcommittee  meetings  are  presented  at  the  next  full  Steering  Committee 
meeting . 


4.3.3  Configuration  Requirements  Committee.  The  Program  Action  Officer  (PAO) 
from  each  participating  MAJCOM  and  HQ  USAP  are  designated  as  chairmen  of  the 
Configuration  Requirements  Committee  (CRC)  for  their  organization.  Each 
MAJCOM  APIRMS  CRC  functions  as  an  Information  Systems  Working  Group  of  the 
MAJCOM  Information  Systems  Requirement  Board  (AFR  700-5).  The  HQ  USAP  CRC 
represents  the  various  participating  Air  Staff  offices.  The  HQ  USAF  Committee 
has  the  same  functions  and  responsibilities  for  Air  Staff  Users  that  the 
MAJCOM  Conf iguration  Requirements  Committees  have  for  their  respective  users. 
The  CRCs  will  consist  of  the  PAO,  a  representative  of  each  participating 
subordinate  unit  (or  directorate  in  the  case  of  the  Air  Staff)  and  such  other 
members  as  the  MAJCOM  and  OPR  may  wish  to  include.  The  CRCs  meet  quarterly, 
prior  to  the  quarterly  APIRMS  System  Status  Review  meeting.  The  CRCs  are 
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responsible  for  formulating  recommendations  to  present  to  the  Steering 
Committee  concerning  their  AFIRMS  requirements,  their  EIP  Segment  Plan,  and 
any  other  matters  of  AFIRMS  interest  originating  from  users  within  their 
organizations . 


4.4  Functional  Baseline.  The  OPR,  considering  recommendations  of  the  AFIRMS 
Steering  Committee,  is  responsible  for  identifying  the  AFIRMS  functional 
baseline  configuration  items  and  approving  changes  thereto.  The  Functional 
Baseline  is  the  culmination  of  the  AFIRMS  planning  process.  Functional 
baseline  conf iguration  items  consist  of  the  inventory  of  AFIRMS  functional 
hardware  and  software  modules  and  certain  AFIRMS  documents.  See  Figure  5-1, 
AFIRMS  Configuration  Items,  for  a  schematic  representation  of  the  Functional 
Baseline . 

The  Configuration  Management  Suppor-i,  Plan  is  the  repository  for  the 
inventory  of  Functional  Baseline  configuration  items.  Descriptions  of 
functional  requirements  for  these  modules  may  be  found  in  the  AFIRMS 
Functional  Description  document.  Examples  and  discussions  of  those  modules 
which  were  developed  or  implemented  during  the  AFIRMS  Learning  Prototype  Phase 
(LPP)  are  found  in  the  AFIRMS  Product  Descriptions  Document  and  the  AFIRMS 
Transforms  and  Models  Document.  The  Functional  Baseline  items  are  initially 
statements  of  functional  requirements.  These  statements  are  developed  into 
functional  specifications  and  distrubuted  over  users  to  form  the  Allocate! 
Baseline . 


K-'i 


Four  AFIRMS  documents  comprise  the  AFIRMS  Functional  Basel  ir.°.  The 
Baseline  documents  listed  below  establish  the  basic  charter  of  AFIRMS,  i-'-fln 
the  boundaries  of  the  AFIRMS  program,  identify  the  Air  For  :e  systems  wi tn 
which  AFIRMS  is  to  interface,  identify  and  prioritize  the  fin-*:  onl  mo! 
of  AFIRMS,  and  provide  for  support  of  AFIRMS  development.  T"h^  ~r;- 
responsible  for  preparation  of  these  documents. 


!#: 
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•  Information  System  Requirements  Document  (ISRD) 

•  Management  Plan 

•  Program  Management  Directive(s)  PMD 

•  APIRMS  Functional  Description  (PD) 

The  APIRMS  functional  modules  and  the  documents  specified  above  constitute  the 
APIRMS  Functional  Baseline.  This  baseline  serves  as  the  basic  frame  of 
reference  for  organizing,  directing  and  controlling  the  APIRMS  program. 


4.5  Configuration  Identification. 

APIRMS  configuration  items  are  of  five  types: 

•  Functional  (Product)  modules 

•  Documents 

•  Product  Code 

•  System  Software 

•  System  Hardware 

One  of  the  objectives  of  the  APIRMS  Management  Plan  is  to  provide 
centralized  control  and  decentralized  execution  of  the  AFIRMS  program.  AFIRM3 
is  to  be  provided  to  each  Air  Force  operational  command  (accommodating  their 
individual  requirements),  with  implementation  extending  over  a  number  of 
years.  At  the  same  time  APIRMS  must  provide  an  Air  Force  wide  combat 
capability  assessment  in  addition  to  assessments  at  the  MAJCOM  and  unit 
levels.  These  factors  requi  central  visibility  over  APIRMS  worldwiie 
requirements  during  the  evolutionary  implementation.  The  large  scope  of  the 
AFIRMS  implementation  requires  a  decentralized  execution  of  AFIRMS 
implementation  in  order  to  achieve  a  worldwide  AFIRMS  capability  that  fits  the 
actual  requirements  of  the  users  as  soon  as  possible.  The  modular  approach  to 
APIRMS  development  provides  the  means  by  which  the  centralized  control  and 
decentralized  execution  can  be  accomplished.  The  fundamental  element  of  this 
modular  approach  i3  the  configuration  item. 
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The  OPR  approves  all  functional  and  allocated  baseline  versions  of 
configuration  items.  The  PMO  approves  product  baseline  versions  of  the 
configuration  items.  Functional  and  allocated  baseline  configuration  items 
consist  of  system  documents  and  modules  of  AFIRMS  functionality,  both  software 
and  hardware.  Product  baseline  configuration  items  consist  of  user  documents, 
program  code,  system  software,  and  hardware.  Functional  Baseline  issues  are 
contained  in  Section  4,  Planning  AFIRMS,  while  Allocated  Baseline  issues  are 
in  Section  5,  Organizing  AFIRMS,  and  Product  Baseline  issues  are  in  Section  6, 
Directing  AFIRMS. 

Configuration  items  may  be  identified  by  the  OPR  to  fulfill  the  essential 
functions  of  AFIRMS  which  are  combat  capability  assessment  and  dollars  to 
readiness  assessments.  In  addition,  the  Program  Action  Officers,  acting 
through  the  Steering  Committee,  may  recommend  other  requirements  necessary  to 
support  the  basic  AFIRMS  functions  for  certification  as  configuration  items. 
The  OPR,  considering  the  recommendations  of  the  Steering  Committee,  assigns 
order-of-precedence  priorities  to  each  AFIRMS  configuration  item  in  order  to 
focus  resource  allocation  and  development  attention  on  the  high  priority 
AFIRMS  requirements  first. 


4.5.1  AFIRMS  Functionality  Modules.  A  number  of  functions  must  be 


accomplished  to  effect  the  essential  charters  of  AFIRMS  (readiness  assessment 
and  dollars- to-readiness ) .  The  collection  of  these  functions  constitutes  the 
AFIRMS  functional  baseline.  Examples  of  functional  modules  which  are 
configuration  items  are: 


AFIRMS  Capability  Assessment  Model 
AFIRMS  Dollars  to  Readiness  Model 
Integrated  Capability  Assessment  Display 
Process  Status  Display  for  Batch  Processes 
AFIRMS  Security  Package 
!Jnit  Status  Display 
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•  APIRMS  Tasking  Model 

•  APIRMS  Resources  Model 

•  APIRMS  Intersite  Communication 

•  System  Interfaces 

The  Configuration  Management  Support  Plan  (Annex  C  of  this  Management 
Plan)  is  the  repository  for  the  inventory  of  functional  modules  comprising  th 
APIRMS  Functional  Baseline. 

Not  all  APIRMS  functional  modules  are  needed  by  each  APIRMS  user. 
Therefore,  the  distribution  of  modules  over  users  provides  relevant  AFIRMS 
functionality  where  needed.  This  distribution  of  APIRMS  configurations  items 
among  the  AFIRMS  user  community  forms  the  APIRMS  Allocated  Baseline.  The 
Evolutionary  Implementation  Plan  (EIP)  is  the  repository  for  the  APIRMS 
Allocated  Baseline,  with  each  EIP  Segment  Plan  containing  the  inventory  of 
APIRMS  functional  modules  applicable  to  that  particular  APIRMS  segment. 

Prototyping  efforts  may  be  used  to  assist  in  defining  functional 
requirements  or  to  explore  options  for  achieving  functional  requirements. 

Such  prototypes  are  controlled  as  a  preliminary  version  of  the  configuration 
item  being  prototyped.  Specifications  and  other  documentation  for  these 
configuration  items  start  with  the  detailing  of  the  prototyping  effort  to  be 
accomplished  for  the  configuration  item  rather  than  the  requirements  for  the 
configuration  item's  operational  functional  module. 


4.5.2  AFIRMS  Documentation.  Certain  key  AFIRMS  documents  are  designated  as 
APIRMS  configuration  items.  All  changes  to  these  documents  are  subject  to 
formal  configuration  change  control  procedures  as  detailed  in  the 
Configuration  Management  Support  Plan,  Annex  C  of  this  document.  The 
following  APIRMS  d  'uments  are  designated  as  configuration  items: 

•  Information  System  Requirements  Document  (ISRD’i 

•  Program  Management  Directive(s)  (PMD) 

•  Management  Plan 
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specifically  developed  within  AFIRMS.  Operating  systems ,  database  management 
systems,  compilers,  and  database  servers  are  examples  of  system  software  which 
requires  the  same  configuration  management  as  the  AFIRMS  product  (functional) 
modules.  Support  or  system  software  items  are  included  in  the  functional, 
allocated,  and  product  baselines  in  the  same  manner  as  the  AFIRMS  functional 
product  modules. 

4.5.5  AFIRMS  Hardware.  Hardware  functional  modules  are  also  cntrolled  within 
AFIRMS  configuration  management  baselines  in  the  same  manner  as  the  AFIRMS 
product  modules.  Just  as  there  is  a  set  of  software  functional  requirements 
in  the  Functional  Baseline,  so  also  there  are  equipment  functional 
requirements.  These  equipment  requirements  are  developed  into  functional  and 
product  specifications  for  use  in  procurement  in  the  same  manner  as  the  AFIRMS 
software  products. 


•  Functional  Description 

•  System  Specification 

•  Data  Requirements  Document 

•  Economic  Analysis 

•  Evolutionary  Implementation  Plan  Annex  to  the  Management  Plan  (with 
Appendices) 

•  Transforms  and  Models  Descriptions  (with  Annexes) 

•  Product  Descriptions  Document  (with  Annexes) 

•  Functional  Specifications 

•  Subsystem  Specifications  (HQ  USAF;  MAJCOM;  UNIT) 

•  Database  Specifications  (HQ  USAF;  MAJCOM;  UNIT) 

•  Program  Specifications 

•  Hardware  Specifications 

•  Conf iguration  Management  Support  Plan  Annex  to  the  Management  Plan 

•  Systems  Interface  Support  Plan  Annex  to  the  Management  Plan 

•  Security  Support  Plan  Annex  to  the  Management  Plan 

•  Training  Support  Plan  Annex  to  the  Management  Plan 

•  Maintenance  Support  Plan  Annex  to  the  Management  Plan 

•  Manpower  Support  Plan  Annex  to  the  Management  Plan 

•  Users  Manuals 

•  Operators  Manuals 

4.5.3  AFIRMS  Program  Code.  AFIRMS  program  code  for  the  functional  products, 
both  source  and  object  code,  i3  subject  to  configuration  control.  As  the 
Allocated  Baseline  functional  module  configuration  items  are  ieveloped,  teste 
and  fielded,  the  various  versions  of  the  computer  programs  comprising  those 
modules  must  be  managed.  The  PMO  is  the  approving  authority  for  Product 
Baseline  changes  to  functional  module  program  code.  Refer  to  Section  7, 
Controlling  AFIRMS,  for  details  on  AFIRMS  configuration  item  status  accountln 

4.5.4  AFIRMS  System  Software.  Computer  software  modules  necessary  to  supper 
AFIRMS  functional  products  is  also  subject  to  configuration  management, 
whether  such  software  i3  commercially  available  "off-the-shelf"  or 
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SECTION  5.  ORGANIZING  AFIRMS 


Organizing  AFIRMS  identifies  how  AFIRMS  is  to  be  implemented. 


5.1  Organizing  Objectives.  The  objectives  of  organizing  AFIRMS  are  to: 

•  Establish  and  maintain  the  AFIRMS  Allocated  Easeline. 

•  Specify  the  timing  for  AFIRMS  interface  with  other  Air  Force  systems 

•  Assign  AFIRMS  functional  modules  to  participating  commands,  with 
priority  of  implementation  for  each  module. 

•  Establish  and  maintain  the  AFIRMS  Evolutionary  Implementation  Plan 
( EIP) . 

•  Provide  the  information  necessary  to  prepare  and  defend  the  AFIRMS 
budget . 

5.2  Office  of  Primary  Responsibility.  The  Office  of  Primary  Responsibility 
develops  and  maintains  the  AFIRMS  Evolutionary  Implementation  Plan. 

The  OPR  consolidates  and  coordinates  the  EIP  Segment  Plans  for  each  MAJCOM  as 
well  as  the  Segment  Plan  Tor  the  Air  Staff.  After  considering  the 
recommendations  of  the  PMO  and  the  Steering  Committee,  the  OPR  approves  the 
EIP  and  associated  Segment  Plans.  The  approved  EIP  constitutes  the  AFIRMS 
Allocated  Baseline  document. 


5.3  Steering  Committee.  The  role  of  the  Steering  Committee  in  organizing 
AFIRMS  is  to  bring  together  all  of  the  issues  associated  with  the  EIP  so  that 
tney  can  be  resolved  in  a  comprehensive  and  coordinated  manner.  The  Steering 
Committee  members  contribute  to  the  EIP  preparation  by  representing  the  views 
needs,  and  priorities  of  their  respective  MAJCOMs  or  offices.  A  draft  EIP  is 
prepared  by  the  OPR  based  upon  the  inputs  of  the  Steering  Committee  members, 
budgetary  considerations,  and  overall  system  priorities.  The  committee 
members  coordinate  the  draft  EIP  (as  the  proposed  Allocated  Baseline)  at  thei 
respective  commands  prior  to  final  approval  by  the  OPR. 
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5.4  Allocated  Baseline.  The  AFIRMS  Allocated  Baseline  is  embodied  in  the 
AFIRMS  Evolutionary  Implementation  Plan  (EIP),  Annex  B  of  the  Management  Plan, 
published  under  separate  cover.  The  OPR  is  responsible  for  preparation  and 
coordination  of  the  Evolutionary  Implementation  Plan  (EIP).  The  Program 
Action  Officer  (PAO)  for  HQ  USAF  and  each  major  command  (MAJCOM)  is 
responsible  for  preparation  and  coordination  of  their  respective  Segment  Plan 
within  the  Evolutionary  Implementation  Plan.  The  EIP  is  revised  annually  to 
reflect  the  results  of  the  Planning,  Programming  and  Budgeting  System  (PPBS) 
cycle.  The  OPR  is  the  approving  authority  for  the  EIP  and  its  component 
Segment  Plans. 

The  EIP  is  the  repository  for  the  results  of  AFIRMS  organizing  efforts. 

It  contains  an  index  of  Allocated  Baseline  software  configuration  items  as 
well  as  the  plan  for  deriving  and  implementing  the  Product  Baseline.  Each 
Segment  Plan  contains  the  index  of  Allocated  Baseline  software  items  relevant 
to  that  segment  of  AFIRMS.  The  index  provides  a  reference  to  the  AFIRMS 
master  library  documents  pertinent  to  each  Configuraton  Item.  The  Allocated 
Baseline  for  an  AFIRMS  segment  may  be  partitioned  into  blocks  of  functionality 
which  are  detailed  and  implemented  over  time  within  the  evolutionary 
implementation  concept  of  AFIRMS  implementation.  However,  all  Allocated 
Baseline  functional  configuration  items  are  scheduled  over  the  implementation 
blocks  of  each  segment  plan.  The  EIP  serves  as  the  basic  frame  of  reference 
for  directing  and  controlling  the  AFIRMS  program.  Specifically ,  the  Allocated 
Baseline  embodied  in  the  EIP  establishes  the  overall  AFIRMS  system 
architecture  by  mapping  the  Functional  Baseline  Configuration  Items  to  the 
user  community. 


5.5  Configuration  Control.  The  AFIRMS  Steering  Committee  serves  as  the 
AFIRMS  Configuration  Control  Board.  As  Chairman  of  the  Steering  Committee, 
tne  OPR  is  also  Chairman  of  the  Configuration  Control  Board.  The 
Conf iguration  Control  Board  is  responsible  for  the  systematic  evaluation, 
coordination,  approval  and  implementation  of  all  changes  to  functional  and 
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allocated  baseline  configuration  items  after  they  are  identified  as  a 
configuration  item  in  the  planning  process.  The  PMO  has  the  same 
responsibilities  for  the  Product  Easeline  and,  additionally,  prepares  a 
summary  report  of  all  such  changes  for  the  quarterly  System  Status  Review 
meetings.  The  configuration  item  is  the  mechanism  for,  and  the  Allocated 
Baseline  the  result  of,  organizing  APIRMS. 


5.5.1  AFIRMS  Software  and  Hardware.  APIRMS  functional  modules  are  allocated 
to  the  user  community  as  APIRMS  is  organized  over  participating  Air  Force 
commands.  AFIRMS  functional  modules  are  assigned  based  upon  user  needs.  Not 
all  modules  are  necessarily  required  by  each  user.  However,  all  APIRMS 
modules  are  allocated  to  at  least  one  user. 

Functional  requirements  identified  for  each  module  during  the  APIRMS 
planning  process  are  expanded  into  detailed  functional  specifications  during 
the  organizing  of  AFIRMS  in  preparation  for  development  of  the  product 
specifications.  In  some  cases,  the  detailed  requirements  may  vary  between 
users  allocated  the  same  APIRMS  functional  module.  These  variations  are 
typically  accommodated  in  a  functional  module  by  providing  user  established 
variables  in  a  set  of  parametric  tables.  Each  different  set  of  such  user 
table  values  constitutes  a  variation  of  the  functional  module.  When  user 
accommodation  is  not  feasible  using  these  parametric  tables,  a  separate 
version  of  the  functional  module  is  provided.  In  either  case,  the 
configuration  status  accounting  system  must  provide  central  visibility  of 
these  module  differences  at  the  Product  Baseline  level  in  order  to  maintain 
the  data  integrity  of  the  APIRMS  assessment  aggregations  as  well  as  to 
facilitate  central  analysis  and  resolution  of  system  problems. 

Therefore,  in  organizing  the  APIRMS  Conf igura tion  Baselines,  the 
Configuration  Status  Accounting  System  provides  for  tracking  of  configuration 
items  to  the  version/variation  level  of  ietail  as  well  as  to  the  using 
commands  and  fjnctional  users  within  the  using  command.  Thus,  at  the  highest 
(planning)  level,  status  accounting  for  the  Functional  Baseline  is  merely  an 


AF -30 1  10/55  dh 


5-3 


inventory  of  configuration  items,  that  is,  functional  modules  without  version 
variability  and  without  assigned  users.  At  the  next  highest  (organizing) 
level,  status  accounting  for  the  Allocated  Baseline  adds  the  inventory  of 
users  to  each  functional  module.  Finally,  at  the  lowest  Configuration  Status 
Accounting  (directing)  level,  the  Product  Baseline  adds  the  inventory  of 
module  versions  and  variations  (including  their  component  program  code).  A 
graphic  depiction  of  this  configuration  item  organization  is  shown  in  Figure 
5-1,  APIRMS  Configuration  Items.  The  PMO  is  responsible  for  establishing  and 
operating  an  AFIRMS  Conf iguration  Status  Accounting  System  which  will 
accomplish  these  requirements. 

AFIRMS  system  configuration  control  is  handled  exactly  the  same  as  the 
AFIRMS  functional  software  discussed  above.  For  system  software,  the 
functional  modules  identify  system  functions  rather  than  AFIRMS  functions. 
Examples  of  these  system  functions  are  a  data  base  management  system,  a 
securi ty/access  control  function,  a  network  communication  function,  and  an 
operating  system. 


5«5»2  AFIRMS  Documentation.  Additional  documents  also  result  from  the  AFIRMS 
organizing  efforts.  The  OPR  is  responsible  for  development  of  the  following 
documents  which  comprise  the  documentation  portion  of  the  Allocated  Baseline: 

•  System  Specification 

•  Evolutionary  Implementation  Plan  Annex  to  the  Management  Plan  (with 
Appendices) 

•  Economic  Analysis 

•  Transforms  and  Models  Descriptions 

•  Product  Descriptions  (with  Annexes) 

•  Functional  Specifications 

•  Data  Requirements  Document 

•  Configuration  Management  Support  Plan  Annex  to  the  Management  Plan 

•  Systems  Interface  Support  Plan  Annex  to  the  Management  Plan 

•  Security  Support  Plan  Annex  to  the  Management  Plan 

•  Manpower  Support  Plan  Annex  to  the  Management  Plan 
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SECTION  6.  DIRECTING  APIRMS 

Directing  APIRMS  accomplishes  the  next  step  in  the  EIP. 


The  objectives  of  directing  APIRMS  are  to: 


•  Establish  and  maintain  the  APIRMS  Product  Baseline 

•  Execute  the  Evolutionary  Implementation  Plan 

•  Report  status  of  the  Evolutionary  Implementation  Plan 


6.2  Program  Management  Office.  The  PMO  develops,  installs  and  updates  APIRMS 
during  the  Evolutionary  Implementation  Plan  period.  At  the  conclusion  of  the 
EIP  period,  responsibility  for  APIRMS  (as  an  Air  Force  Standard  System)  is 
transferred  to  the  appropriate  Air  Forces  systems  agency  for  support  and 
maintenance.  The  Program  Management  Office  (PMO)  is  responsible  for  ensuring 
that  appropriate  work  orders  are  issued  to  execute  the  elements  of  the  EIP. 

The  PMO  executes  the  Evolutionary  Implementation  Plan  (EIP)  through  AFIRMS 
agents  such  as  the  Program  Action  Officers,  in-house  Air  Force  agencies  and 
contractors.  Work  orders  for  in-house  Air  Force  agencies  are  issue!  as 
Program  Ifenagement  Directive  supplements  in  accordance  with  the  requirements 
of  AFR  800-2.  Work  orders  for  contractors  are  issued  in  accordance  with  Air 
Force  contracting  procedures. 


6.3  Execution  of  AFIRMS.  As  AFIRMS  executive,  the  FMO  is  responsible  for 
ensuring  that  each  EIP  allocated  baseline  action  item  has  an  agent  assigned 
and  performing  in  accordance  with  the  implementation  schedules  of  the  EIP, 
particularly  the  detailed  schedules  within  each  EIP  segment  plan.  The 
Evolutionary  Implementation  Plan  (EIP)  is  the  master  build  plan  for  AFIRMS. 

It  is  organized  in  segments,  one  for  each  MAJCOM  and  one  for  HQ  USAF.  Each 
segment  ha3  a  detailed  breakdown  of  the  implementation  plan  for  the  hardware, 
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to  that  segment.  Subsets  of  these  baseline  configuration  items  may  be 
implemented  as  functional  blocks  over  time.  Each  of  these  block 
implementations  is  accomplished  in  a  series  of  phases:  analysis,  development, 
installation,  operation  and  integration  management.  Refer  to  Annex  B, 
Evolutionary  Implementation  Plan,  published  under  separate  cover,  for  details 
of  EIP  organization  and  responsibilities. 

The  nature  of  the  Evolutionary  Implementation  Plan  provides  maximum 
flexibility  to  the  PMO  for  executing  AFIRMS  since  AFIRMS  Agents  can  be 
assigned  to  accomplish  almost  any  set  of  work  tasks.  Thus,  the  PMO  may  issue 
work  orders  (in-house  or  contractor)  for  an  entire  segment  of  AFIRMS  and  all 
its  component  conf iguration  items  over  all  blocks  of  the  segment  to  execute 
all  phases  of  each  block.  For  example,  the  PMO  may  assign  a  work  order  to 
have  a  single  executive  agent  (say,  the  USAFE  PAO)  accomplish  the  entire  USAFE 
AFIRMS  Segment.  Or,  at  the  other  extreme  of  the  work  assignment  spectrum,  the 
PMO  may  issue  a  work  order  for  an  individual  work  phase  for  a  particular 
configuration  item  in  a  particular  block  of  a  particular  segment.  An  example 
•night  be  the  assignment  of  a  particular  executive  agent  (e.g.,  a  contractor) 
to  act.  mplish  the  requirements  analysis  phase  for  one  configuration  item 
(e.g.,  the  capability  assessment  model  configuration  item)  within  the  first 
block  of  one  AFIRMS  segment  (e.g.,  the  MAC  segment).  There  are  numerous 
options  for  executing  AFIRMS  between  these  two  extremes.  The  PMO  can 
therefore  lirect  the  best  combination  of  resources  at  the  various  components 
of  AFIRMS  execution.  For  example,  analysis  and  development  phases  of  all 
AFIRMS  model ing/simulation  configuration  items  over  the  entire  Allocated 
Baseline  might  be  competitively  awarded  to  the  contractor  with  the  best  C03t 
effective  technical  solution/approach  to  capability  assessment  and 
iol 1 ars- to- read iness  modeling. 

HQ  USAF  and  MAJCOM  PAOs  assist  the  PMO  in  assigning  responsibilities  for 
their  respective  segment  plans.  The  PAOs  represent  the  requirements, 
suggestions  and  preferences  of  their  commanders  and  constituent  users  to  the 
PMO  for  consideration  in  the  preparation  of  the  segment  Product  Baseline. 
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6.3.1  AFIRMS  Agents.  The  AFIRMS  team  includes  the  OPR  (for  Functional  and 
Allocated  Baseline  development),  the  PMO  (for  Product  Baseline  development) 
and  internal  Air  Force  agencies  or  contractors  for  Functional  and  Product 
Baseline  implementations.  The  OPR  and  the  PMO  are  AFIRMS  managers.  Air  Force 
agencies,  contractors,  and  the  PAO  for  each  MAJCOM  and  for  HQ  USAF  are 
implementing  agents.  The  PMO  may  issue  work  orders  to  AFIRMS  Agents  (either 
Air  Force  agencies  or  contractors)  to  support  AFIRMS  managers  (OPR  and  PMO)  in 
fulfilling  their  task  responsibilities.  For  example,  the  development  of  the 
functional  specification  for  a  functional  baseline  item  (an  OPR 
responsibility)  may  be  contracted  for  accomplishment  or  it  may  be  developed  by 
an  internal  Air  Force  agency.  In  either  case,  the  PMO  would  have  the 
AFIRMS  Agent  work  directly  with  the  OPR  3ince  the  work  relates  to  an  OPR 
responsibility — the  Functional  Baseline.  Likewise,  the  central  AFIRMS  Program 
Library  might  be  maintained  for  the  PMO  under  contract,  or  it  may  be 
maintained  by  an  appropriate  Air  Force  Agency,  or  under  contract  for  an 
appropriate  Air  Force  agency.  Figure  6-1,  AFIRMS  Management  Schema,  shows  the 
operating  relationships  among  AFIRMS  agents. 


6.3.2  Execution  Actiona.  In  the  concept  of  the  EIP  and  this  management  plan, 
there  are  two  basic  types  of  actions  necessary  to  implement  AFIRMS: 
implementative  and  administrative.  The  management  plan  defines  and  assigns 
administrative  and  associated  support  task  responsibilities.  The  Evolutionary 
Implementation  Plan  defines  and  assigns  detailed  analysis,  development, 
installation  and  operations  task  responsibilities.  Both  Functional  Baseline 
and  Product  Baseline  actions  (such  as  functional  and  product  specification 
development)  are  included  in  the  EIP.  Since  the  OPR  and  PMO  staffs  are  small, 
virtually  all  of  the  implementation  actions  are  accomplished  through  PMO 
tasking  of  AFIRMS  Agents.  These  agents  accomplish  Allocated  Baseline 
Configuration  Items  within  the  phases  of  one  or  more  blocks  of  a  Segment  Plan. 
In  the  Analysis  Phases  of  allocated  baseline  work  set  forth  in  the  EIP,  the 
OPR  is  the  authority  for  all  Functional  Baseline  tasks  while  the  PMO  is  the 
technical  authority  for  the  Product  Baseline.  The  PMO  is  the  technical 
authority  for  the  Development,  Installation,  and  Operation  Phases  of  the 
segment  implementations  while  the  OPR  is  the  authority  for  the 
Integration/Management  Phases. 


GUIDANCE.  AS  NEEDED 


It  may  be  necessary  for  the  OPR  and/or  the  PMO  to  have  AFIRMS  Agents 
accomplish  many  of  the  administrative  actions.  Actions  that  might  be 
accomplished  by  executive  agents  include  maintaining  the  configuration  item 
baseline  indexes  (Functional,  Allocated,  Product),  operating  the  Configuration 
Status  Accounting  System,  maintaining  the  master  AFIRMS  Program  Library, 
developing  Management  Plan  Support  Annexes,  maintaining  an  AFIRMS  testbed 
system  or  performing  other  efforts  beyond  the  capacity  of  the  OPR  or  PMO 
staffs . 


6.3.3  Execution  Status.  The  PMO  conducts  quarterly  System  Status  Reviews  so 
that  the  entire  AFIRMS  management  team  may  review  program  progress.  The  PMO 
prepares  the  agenda  to  ensure  review  of  implementation  aspects  embodied  in  the 
SIP  and  the  administrative  aspects  embodied  in  the  Management  Support  Plan 
with  its  support  annexes  as  well  as  budgetary  status.  This  agenda  includes, 
as  a  minimum: 

•  Program  Management  Milestones  Schedule 

•  Functional  Baseline  Status 

•  Allocated  Baseline  Status 

•  Product  Baseline  Status 

•  Status  of  Support  Plans  (and  their  execution) 

•  Master  EIP  Schedule 

•  EIP  Segment  Schedules 

•  Budget  Status  and  Projections 

•  Summary  of  Problems  (both  program  and  system  problems  with  corrective 
actions) 


6.4  Product  Baseline.  The  PMO  develops,  approves  and  executes  the  Product 
Baseline.  This  baseline  is  derived  from  the  Allocated  Baseline,  which 
distributes  Functional  Baseline  Configuration  Items  over  AFIRMS  segments  and 
over  time  as  reflected  in  the  EIP.  The  Product  Baseline  includes  the  set  of 


AF-001  10/85  dh 


6-5 


software  and  hardware  product  specifications  necessary  to  accomplish  the 
AFIRMS  functional  requirements  as  well  as  user  oriented  documents.  The 
Product  Baseline  is  indexed  by  the  most  complete  form  of  the  Configuration 
Item  Index  (CII)  number  (i.e.,  entries  in  all  components  of  the  CII  number) 
together  with  the  AFIRMS  user  designation,  as  shown  in  Figure  5-1.  Note  that 
the  program  management  information  for  the  AFIRMS  Agent  assigned  to  a  Product 
Baseline  Configuration  Item  is  associated  with  Product  Baseline  CIIs. 
Therefore,  in  effect,  the  product  baseline  includes  the  AFIRMS  Agent 
responsible  for  accomplishing  each  component  configuration  item. 

The  certification  of  the  Product  Baseline  is  accomplished  by  the  Quality 
Assurance  (QA)  AFIRMS  Agent  whose  representive  on  the  AFIRMS  management  team 
is  the  QA  PAO.  Details  of  Product  Baseline  certification  procedures  are 
contained  in  Annex  C,  Configuration  Management  Support  Plan. 


6.5  Configuration  Control.  The  PMO  is  the  Product  Baseline  Configuration 
Approval  Authority.  The  PMO  is  therefore  responsible  for  systematic 
evaluation,  coordination ,  approval  and  implementation  of  all  changes  to  the 
Product  Baseline.  The  PMO  also  consolidates  and  prepares  proposed  changes  to 
the  Functional  or  Allocated  Baselines  for  disposition  by  the  Configuration 
Control  Board.  The  PMO  is  also  responsible  for  AFIRMS  "build"  releases  and 
for  releases  and  revisions  of  AFIRMS  or  vendor  software  and  hardware  items. 
Such  release  constitutes  authority  to  proceed  with  the  installation  of  the 
build  or  a  revision  at  AFIRMS  user  sites.  Such  installations  are  controlled 
within  the  Conf iguration  Status  Accounting  System.  The  Product  Baseline 
Configuration  Items  of  AFIRMS  consist  of  computer  software  and  hardware 
specifications,  certain  additional  documents,  equipment,  and  software  code. 


6.5.1  Software.  The  PMO  develops  product  specifications  for  each  software 
functional  specification  contained  within  the  Allocated  Baseline.  Both 
functional  (user)  and  system  (support)  software  is  then  developed  or  procured 
"off  the  shelf"  based  upon  these  product  specifications.  The  software  is  unit 
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tested  and,  after  QA  certification,  installed  by  the  PMO  or  by  an  AFIRMS  Agent 
responsible  to  the  PMO.  See  Section  6.14  and  Annex  C,  Configuration  Management 
Support  Plan,  for  QA  certification  responsibilities  and  procedures. 


6.5.2  AFIRMS  Documentation.  AFIRMS  directing  efforts  add  additional 
documentation  configuration  items  to  the  AFIRMS  Configuration  Item  Index. 
PMO  is  responsible  for  producing  these  documents.  Documents  forming  the 
documentation  portion  of  the  Product  Baseline  are: 


Subsystem  Specifications  (HQ  USAF,  MAJCOM,  UNIT) 

Database  Specifications  (HQ  USAF,  MAJCOM,  UNIT) 

Program  Specifications 

Hardware  Specifications 

Training  Support  Plan 

Maintenance  Support  Plan 

Users  Manuals 

Operators  Manuals 


6.5.3  Hardware.  The  PMO  translates  the  functional  specifications,  which  were 
prepared  as  part  of  the  Allocated  Baseline,  into  product  specifications.  The 
requisite  hardware  is  then  procured  in  synchronization  with  the  EIP 
installation  schedules.  Maximum  utilization  is  made  of  existing  Air  Force 
standard  procurement  sources.  Installation,  check  out  and  turnover  then 
proceed  in  accordance  with  the  plans  established  in  the  appropriate 
installation  phase  of  the  EIP  Segment  Plan. 


6.6  Technical  Direction.  The  PMO  is  responsible  for  technical  direction  of 
the  AFIRMS  program.  For  contractor  AFIRMS  Agents,  this  direction  is 
accomplished  through  normal  contracts  procedures  which  are  coordinated  by  the 
AFIRMS  Acquisition/ Contrac ts  Program  Action  Officer  (PAO).  (See  Section  3*2, 


AF-001  10/35  dh 


Program  Organization.)  For  in-house  Air  Force  Agencies  or  commands,  PMO 
direction  is  accomplished  through  the  Program  Management  Directive  mechanism 
and  supplements  thereto. 


) 


Responsibility  for  technical  guidance  necessary  to  effect  actions  directed 
by  the  PMO  may  reside  with  another  member  of  the  AFIRMS  management  team.  In 
such  cases  the  PMO  directives  will  identify  the  functional  authority  from 
which  the  AFIRMS  Agent  will  receive  technical  guidance.  For  example,  AFIRMS 
Agents  directed  by  the  PMO  to  accomplish  tasks  relating  to  the  Functional 
Baseline  or  Allocated  Baseline  will  receive  technical  guidance  from  the  OPR 
rather  than  the  PMO.  In  any  case,  the  PMO  is  responsible  for  the  initiating 
instructions  to  effect  the  requirements  of  the  Evolutionary  Implementation 
Plan . 
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SECTION  7.  CONTROLLING  AFIRMS 

Controlling  AFIRMS  provides  visibility  of  the  current  status  of  AFIRMS. 


7.1  Controlling  Objectives.  The  objectives  of  AFIRMS  controlling 
activities  are  to: 

f  Monitor  AFIRMS  implementation  status 

•  Provide  centralized  AFIRMS  record  keeping 

•  Administer  the  AFIRMS  Conf iguration  Status  Accounting  System 

•  Provide  information  necessary  to  support  AFIRMS  contracts 
administration 

•  Provide  for  technical  oversight  of  both  in-house  and  contractor 
AFIRMS  technical  activities 

Technical  control  of  AFIRMS  is  achieved  through  operation  of  the  AFIRMS 
Program  Library,  through  AFIRMS  Configuration  Status  Accounting,  through 
Conf iguratic.i  Change  Control  procedures,  through  Configuration  Status  Auditing 
and  through  technical  review  of  in-house  or  contractor  activities. 


7.2  AFIRMS  Program  Library.  The  ?M0  is  responsible  for  managing  the  program 
library.  Since  the  implements t ion  of  AFIRMS  will  be  an  evolutionary  process, 
AFIRMS  configuration  as  it  exists  at  one  site  will  not  necessarily  be  in  the 
same  evolutionary  stage  as  the  configuration  existing  at  another  site.  A 
program  library  contains  copies  of  ail  Product  Baseline  software  releases  or 
versions  (both  source  an  1  executable  eoie)  which  have  been  instailei  at  any 
site.  This  program  library  also  contains  a  copy  of  all  studies,  analysis 
efforts,  white  papers,  regulations,  manuals,  specifications,  and  other 
iocuments  pertinent  to  AFIRMS  cr  to  its  historic  evolution.  A  copy  of  each 
iteration  of  each  locument  contained  in  tne  AFIRMS  Functional,  Allocated,  and 
Product  Baselines  is  also  maintained  in  the  library.  All  baseline  documents, 
software  releases,  and  hardware  loc umentation  ar«  indexed  by  Conf iguration  Item 
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Index  number.  Other  documents  are  similarly  indexed  when  they  are  applicable 
to  particular  Functional,  Allocated,  or  Product  Baseline  Configuration  Items. 
The  central  program  library  allows  for  the  staged  evolutionary  implementation 
while  accommodating  specialized  variations  at  individual  sites.  This  approach 
supports  centralized  problem  research,  analysis,  and  correction. 


7.3  AFIRMS  Configuration  Status  Accounting  System  (CSAS).  A  configuration 
status  accounting  function  provides  a  mechanism  for  maintaining  a  record  of 
how  the  system  has  evolved  and  the  status  of  the  system  at  any  time  relative 
to  what  appears  in  the  Functional,  Allocated  and  Product  baseline 
documentation.  The  Accounting  System  is  indexed  by  AFIRMS  Configuration  Item 
Index  numbers  (the  structure  of  which  is  discussed  in  Section  5)  for  software, 
hardware,  and  documentation.  Status  accounting  involves  tracking  and 
reporting  the  status  of  all  components  of  the  AFIRMS  system,  software, 
hardware,  and  documentation .  It  is  the  essential  means  whereby  the 
conf iguration  control  activities  are  recorded.  Since  the  worldwide 
operational  AFIRMS  conf iguration  management  problem  is  very  complex,  the  PMO 
must  automate  this  function. 

The  PMO  is  responsible  for  the  design,  implementation  and  operation  of  the 
status  accounting  system  for  AFIRMS.  The  OPR  approves  the  design  of  the 
AFIRMS  Status  Accounting  System.  Assigned  Program  Action  Officers  work  with 
lata  base  engineers  to  develop  and  implement  the  status  accounting  data  base 
and  to  formulate  the  procedures  for  updates  and  report  generation.  The  status 
accounting  system  tracks  the  configuration  of  system  functional  modules  in  use 
at  each  site  (Functional  and  Allocated  Baselines),  as  well  as  the  particular 
program  code,  equipment,  and  documentation  supporting  those  modules  (Product 
Baseline) . 

The  Configuration  Status  Accounting  System  provides  an  automated  mechanism 
for  tracking  the  overall  status  of  the  evolutionary  implementation.  The 
current  AFIRMS  baselines  and  all  requests  for  changes  are  recorded  and 
tracked.  Current  status  and  historic  audit  trails  of  all  sites  and  baseline 
documents  are  maintained  in  the  configuration  status  accounting  data  base. 


7.4  Change  Control.  Change  control,  as  part  of  the  Conf iguration  Status 
Accounting  function,  monitors  requested  changes  to  all  AFIRMS  conf iguratation 
baselines  from  initiation  through  final  disposition.  The  objective  of  change 
control  is  to  ensure  that  changes  modify  the  configuration  only  in  ways 
desired,  approved  and  budgeted.  This  is  accomplished  by  the  use  of  procedures 
for  the  proposal,  evaluation,  approval,  implementation,  and  documentation  of 
all  changes.  Change  control  provides  an  orderly  approach  to  software  change, 
including : 

•  mechanisms  for  changing  configuration  items 

•  recording  and  tracking  of  change  requests  (including  present  status 
of  the  request) 

•  recording  of  actual  changes  made 

•  linking  change  documentation  to  the  actual  software  or  hardware 
changes 

•  configuration  item  change  release  control 

•  identifying  related  configuration  items  that  may  be  effected  by  a 
proposed  change 

Problem/change  reporting  procedures  and  forms  provide  visibility  and 
control  over  the  processing  of  reported  errors  in,  and  proposed  changes  to, 
the  software  system.  These  procedures  and  forms  are  designed  to  ensure 
sufficient  control  while  providing  flexibility  to  correct  or  upgrade  system 
design,  hardware,  software  and  operation.  These  procedures  provide  adequate 
information  for  proper  evaluation  and  tracking,  yet  do  not  require  an 
unreasonable  effort  or  cause  excessive  delay  in  identifying  problems  or  change 
requests . 


7.4.1  Problem/ Action  Reports  (PAR).  Reporting  and  review  of  problems  and 
recommendations  are  accomplished  through  the  use  of  Problem/ Action  Reports 
(PARs)  and  Engineering  Change  Proposals  (ECPs).  PARs  are  generated  by 
development,  test,  or  user  personnel  to  report  errors  or  discrepancies 
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experienced  with  software,  documentation,  or  tests.  PARs  are  also  used  as  a 
mechanism  to  submit  suggestions  for  improvements  to  AFIRMS.  An  initial 
evaluation  of  the  significance  of  the  PAR  and  the  urgency  of  solution  is 
recorded  on  the  PAR  by  the  originator.  The  completed  PAR  is  submitted  to  the 
AFIRMS  Program  Action  Officer  (PAO)  responsible  for  the  AFIRMS  Segment  serving 
the  originator.  The  PAO,  in  coordination  with,  and  with  the  approval  of,  the 
PMO  makes  a  preliminary  determination  for  disposition  of  the  PAR.  If  no 
further  action  is  appropriate  or  the  PMO  approves  the  PAR,  the  PAO  refers  the 
PAR  to  the  appropriate  activity  for  action  and  forwards  a  copy  to  the  PMO  for 
incorporation  into  the  Conf iguration  Status  Accounting  System.  Otherwise,  the 
PAO  forwards  the  PAR  to  the  PMO  for  disposition. 

In  general,  the  PMO  is  authorized  to  approve  PARs  relating  to  the  Product 
Baseline,  only.  All  other  PARs  are  referred  to  the  Configuration  Control 
Board  (i.e.,  the  Steering  Committee)  for  disposition.  However,  if  the  problem 
reported  is  severe  enough  to  cause  system  failure  or  significant  processing 
error,  the  PMO  will  consult  with  the  OPR  and  take  immediate  action  for  an 
interim  solution  regardless  of  the  affected  baseline.  A  quarterly  status 
report  of  all  PAR  actions  is  prepared  by  the  PMO  for  each  quarterly  System 
Status  Review  meeting. 

PARs  relating  to  the  Functional  or  Allocated  Baselines  are  evaluate!  by 
the  PMO  and  solutions  formulated  for  presentation  to  the  CCB  in  the  form  of  an 
Engineering  Change  Proposal  (ECP).  The  PMO  may  also  refer  PARs  involving  the 
Product  Baseline  to  the  CCB  as  an  ECP.  Engineering  Change  Proposals  are 
approved  or  disapproved  by  the  CCB  and  returned  to  the  PMO  for  action. 

All  approved  ECPs  changing  or  enhancing  the  Functional  or  Allocated 
Baseline  and  all  routine,  non-critical  approved  Product  Baseline  PARS  are 
placed  in  the  appropriate  baseline  queue  to  be  incorporated  in  the  next 
revision  of  the  EIP.  Thus,  implementation  of  changes  and  routine  system  fixes 
are  accomplished  within  the  normal  EIP  Segment  planning  process.  Minor  AFIRMS 
patches  and  new  system  software  versions  which  are  wholly  within  the  Product 
Baseline  may  be  issued  periodically  by  the  PMO. 
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7.4.2  Engineering  Change  Proposals  (ECP).  For  ECPs  approved  by  the  CCB,  the 
Configuration  Status  Accounting  System  (CSAS),  and  AFIRMS  program  library 
facilities  are  used  to  implement  and  test  the  modification.  Appropriate 
changes  to  program  code  and  documentation  are  then  made.  Release  of  the 
modification  is  accomplished  under  CSAS  control  after  release  by  the  AFIRMS 
Quality  Assurance  agent. 

Through  the  Configuration  Status  Accounting  System,  every  site's  current 
configuration  is  tracked.  Using  the  centralized  AFIRMS  program  library,  the 
configuration  as  it  currently  exists  at  any  given  site  can  be  recreated  at  a 
central  site  for  software  engineer  use.  This  allows  a  central  team  of 
engineers,  working  from  specifications  and  baseline  code  to  accomplish 
modifications  for  any  particular  application  with  minimal  need  for  travel. 
Modifications,  once  made,  can  then  be  routed  to  the  appropriate  sites  with  the 
conf iguration  status  accounting  data  base  updated  accordingly.  The 
modification  is  not  released  until  the  AFIRMS  Quality  Assurance  agent  verifies 
that  the  approved  change  has  been  accomplished  and  all  documentation  changes 
written.  After  QA  verifies  the  approved  change,  it  is  released  for 
incorporation  into  the  next  baseline  or  inclusion  in  a  patch  release,  as 
appropriate,  with  all  changes  to  hardware,  software  and  documentation 
components  of  the  modification  coordinated  within  the  Configuration  Status 
Accounting  System. 

Status  accounting  information  tracks  the  progress  of  all  approved  changes 
to  the  configuration,  including  entries  for  the  date  of  ECP  submittal,  date  of 
ECP  approval,  engineers  assigned,  expected  data  of  completion,  current  status 
and  expected  date  for  inclusion  in  baseline. 


7.5  Auditing  Configuration  Status.  Configuration  audits  are  held  in  order  to 
ensure  that  software,  hardware,  and  documentation  which  have  been  developed 
fully  meet  AFIRMS  performance  requirements.  Developmental  configuration 
audits,  both  functional  and  physical,  are  accomplished  by  the  PMO.  The 
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purpose  of  these  audits  is  to  check  the  technical  documentation  against  actual 
code  being  delivered  to  ensure  that  it  has  been  developed  in  accordance  with 
the  baseline  configuration  document  specifications.  Installation  audits  are 
the  responsibility  of  the  Quality  Assurance  PAO.  The  installation  audits 
provide  a  verification  of  the  field  installation  which  is  independent  of  the 
user  and  the  developer. 

Configuration  audits  also  apply  to  modification  of  AFIRMS.  As  changes  are 
made  to  AFIRMS  software,  hardware,  and  documentation,  tests  are  conducted  to 
ensure  that  the  changes  do  not  create  problems  in  other  areas  and  that  the  new 
code  accomplishes  the  desired  effect.  These  tests  are  accumulated  within  the 
AFIRMS  program  library. 

Results  of  configuration  audits  are  forwarded  to  the  Configuration  Control 
Board.  Validation  of  AFIRMS  development  is  not  complete  until  the  results 
have  been  approved  by  the  CCB/Steering  Committee. 


7.6  Technical  Control.  The  PMO  is  responsible  for  technical  supervision  of 
in-house  development  agencies  and  all  contractors  performing  AFIRMS 
development  or  implementation  tasks.  To  facilitate  this  technical 
supervision,  information  about  the  contractor  or  in-house  development  agency 
is  incorporated  into  the  Configuration  Status  Accounting  System.  Such 
information  is  cross-referenced  to  the  configuration  item  under  which  the 
development  or  implementation  effort  is  chartered.  Essential 
contractor/agency  information  includes: 


Name  of  company  or  agency 
Name  Project  Manager 
Address  of  Project  Manager 
Phone  number  of  Project  Manager 
Configuration  Item  Index  Number(s) 
Contract  Number(s),  if  applicable 
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